Celery task name not set in span streaming mode

In the span streaming path, the transaction is created with name="unknown celery task" but never updated to the actual task name. The non-streaming path sets transaction.name = task.name (line 349), but the streaming path is missing the equivalent transaction.set_name(task.name) call. This will cause all Celery tasks in span streaming mode to be reported as "unknown celery task" in Sentry, making task identification and debugging impossible.

Suggested fix: Add set_name(task.name) call after creating the span in the span streaming path

Identified by Warden code-review · 8DB-RN4

StreamedSpan not properly closed on error in Anthropic integration

The change filters out StreamedSpan instances from error cleanup, but doesn't add equivalent handling for the new span type. When streaming mode is enabled (trace_lifecycle: stream) and an exception occurs during Anthropic API calls, the StreamedSpan will have its status set to SpanStatus.ERROR by set_span_errored(), but __exit__ will never be called to properly end the span. This leaves the span unclosed and potentially causes incomplete trace data.

Identified by Warden code-review · SR8-YQM

Missing @wraps(f) decorator after removing @ensure_integration_enabled breaks celery-once compatibility

The @ensure_integration_enabled(CeleryIntegration, f) decorator was removed from _inner, but @functools.wraps(f) was not added. The comment at lines 395-399 explicitly warns: "functools.wraps is important here because celery-once looks at this method's name... but if we ever remove the @ensure_integration_enabled decorator, we need to add @functools.wraps(f) here." Without @wraps(f), _inner.__name__ will be '_inner' instead of the original function's name, breaking celery-once integration.

Suggested fix: Add @wraps(f) decorator to the _inner function to preserve the original function's metadata

Identified by Warden code-review · 7EE-X7V

set_origin uses literal string "origin" instead of self.origin

On line 220, sentry_span.set_origin("origin") uses the hardcoded string literal "origin" instead of self.origin. This is inconsistent with all other branches in the same function that correctly use self.origin (lines 225, 235, 240). This causes spans created under a StreamedSpan parent to have an incorrect origin attribute ("origin" instead of the properly configured value like "auto.function.rust_tracing.{identifier}").

Suggested fix: Change the string literal "origin" to self.origin

Identified by Warden code-review · 8Y6-99J

NoOpStreamedSpan.finish() does not restore scope state

When span_streaming is enabled and a NoOpStreamedSpan is returned (e.g., for ignored spans), calling span.start() followed by span.finish() does not properly restore the scope state. NoOpStreamedSpan.start() sets scope.span = self and saves the old span in _context_manager_state, but NoOpStreamedSpan.finish() is a no-op (pass), so scope.span is never restored. This could cause subsequent spans to be incorrectly parented to the no-op span.

Suggested fix: Call span.end() instead of span.finish() since NoOpStreamedSpan.end() properly calls exit() to restore scope state, or fix NoOpStreamedSpan.finish() to also call exit()

Identified by Warden code-review · FYA-VCQ

Missing parent_span in on_parse() causes orphaned spans in streaming mode

In on_parse(), the start_span() call for streaming mode (lines 261-263) does not pass parent_span=self.graphql_span, unlike the equivalent code in on_validate() which correctly passes it. This means parsing spans will not be correctly parented to the GraphQL operation span in streaming mode, causing broken trace hierarchy and incorrect trace visualization in Sentry.

Suggested fix: Add parent_span=self.graphql_span to the start_span() call in on_parse() for streaming mode, matching the pattern used in on_validate().

Identified by Warden code-review · 9Y5-4C6

Missing f-string prefix causes span name to be literal text instead of formatted

In SentrySyncExtension.resolve, the span name is set to "resolving {field_path}" (line 354) but the f prefix is missing. This means the span name will literally be "resolving {field_path}" instead of being interpolated with the actual field path value (e.g., "resolving Query.users"). The async version on line 315 correctly uses an f-string. This will make it difficult to identify which resolver a span corresponds to in Sentry.

Suggested fix: Add the f prefix to make it an f-string

Identified by Warden code-review · D84-YUV

Span not discarded despite 'discarding' warning when sampled is None

At line 418-419, when self.sampled is None, the code logs 'Discarding transaction without sampling decision' but does not return. This allows the span to continue processing and potentially be captured at line 434-435. The legacy implementation in tracing.py (line 1036-1038) correctly returns None after this warning. This inconsistency means spans without sampling decisions may be sent when they should be discarded.

Suggested fix: Add a return statement after the warning to actually discard the span, matching the legacy behavior in tracing.py

Identified by Warden code-review · DBB-FK8

NoOpStreamedSpan missing method overrides will cause AttributeError

NoOpStreamedSpan inherits from StreamedSpan but does not override dynamic_sampling_context(), get_baggage(), or to_baggage(). Since NoOpStreamedSpan sets self.segment = None and does not define _baggage in its __slots__, calling these inherited methods will raise AttributeError. For example, dynamic_sampling_context() at line 524-525 calls self.segment.get_baggage() which will fail with 'NoneType' object has no attribute 'get_baggage'.

Identified by Warden code-review · RKZ-FNB

Tautological assertion compares segment1 trace_id to itself

Line 500 asserts segment1["trace_id"] == segment1["trace_id"] which always passes. Based on the test name test_sibling_segments and the pattern in the subsequent test test_sibling_segments_new_trace (which asserts segment1["trace_id"] != segment2["trace_id"]), this should verify that sibling segments without a new_trace() call share the same trace_id: assert segment1["trace_id"] == segment2["trace_id"]. The test currently provides no coverage for this expected behavior.

Suggested fix: Compare segment1's trace_id with segment2's trace_id instead of itself

Identified by Warden code-review · PVK-5ZM

get_start_span_function returns incompatible function signature in streaming mode

When span streaming is enabled, get_start_span_function() returns sentry_sdk.traces.start_span which only accepts name, attributes, and parent_span parameters. However, callers (google_genai, anthropic, langchain, pydantic_ai, mcp, litellm integrations) pass op, name, and origin as keyword arguments. This will cause a TypeError at runtime when users enable streaming mode with _experiments={"trace_lifecycle": "stream"} and any of these AI integrations are used.

Suggested fix: Update sentry_sdk.traces.start_span to accept and handle **kwargs, or update the function to accept op and origin parameters and forward them appropriately

Identified by Warden find-bugs · UV8-FTU

StreamedSpan created without entering context manager causes silent span loss

In streaming mode, the code creates a StreamedSpan via sentry_sdk.traces.start_span() but never enters its context manager (no .start() call or with statement). When .finish() is called in the finally block, it invokes __exit__() which tries to access self._context_manager_state - an attribute only set in __enter__(). Since this access is wrapped in capture_internal_exceptions(), the AttributeError is silently caught and logged, but _end() is never called. This means GraphQL spans in streaming mode are never actually sent to Sentry.

Suggested fix: Use the span as a context manager by calling .start() before the try/yield block and using .end() in the finally block, matching the pattern used in other integrations like Celery.

Identified by Warden find-bugs · H3C-HLQ

Potential UnboundLocalError for span_ctx variable if exception occurs

The variable span_ctx is declared but not initialized. Inside capture_internal_exceptions(), if an exception occurs after transaction = start_span(...) but before span_ctx = transaction (e.g., during set_origin, set_source, or set_op calls), the transaction is None check passes but span_ctx remains unbound. This would cause an UnboundLocalError at with span_ctx: on line 368.

Suggested fix: Initialize span_ctx to None and check both transaction and span_ctx before using

Identified by Warden find-bugs · SWU-CK2

set_transaction_name crashes when scope has NoOpStreamedSpan due to None segment

When self._span is a NoOpStreamedSpan, isinstance(self._span, StreamedSpan) returns True (since NoOpStreamedSpan inherits from StreamedSpan), but NoOpStreamedSpan.segment is set to None in its __init__. This causes self._span.segment.set_name(name) to raise AttributeError: 'NoneType' object has no attribute 'set_name'. Users can trigger this by calling scope.set_transaction_name() while a NoOpStreamedSpan is the active span (returned when spans are ignored or the SDK is misconfigured).

Suggested fix: Add a check for NoOpStreamedSpan before accessing segment, or check if segment is not None

Identified by Warden find-bugs · 2PK-MMZ

new_trace() doesn't reset propagation context on isolation scope, unlike continue_trace()

The continue_trace() function explicitly sets propagation context on both the isolation scope and current scope (with a comment explaining this is needed 'for compatibility reasons' in span-first mode). However, new_trace() only calls set_new_propagation_context() on the current scope. This asymmetry could lead to stale trace information persisting on the isolation scope when starting a new trace, potentially causing spans to be incorrectly associated with old traces in certain scope configurations.

Suggested fix: Call set_new_propagation_context() on both isolation scope and current scope for consistency with continue_trace()

Identified by Warden find-bugs · 3EK-9CE

Empty dict in ignore_spans config ignores all spans unexpectedly

When an empty dict {} is included in the _experiments.ignore_spans config, the is_ignored_span function will return True for all spans. This happens because name_matches and attributes_match both default to True, and without any 'name' or 'attributes' keys to check, the condition name_matches and attributes_match is always satisfied. This is likely a configuration error by users, and the behavior could cause unexpected loss of all tracing data.

Suggested fix: Add a check to skip dict rules that have neither 'name' nor 'attributes' keys, treating them as no-ops rather than match-all rules.

Identified by Warden find-bugs · AY4-S9N